Minutes, IBIS Quality Committee 14 Oct 2008 11-12 AM EST (8-9 AM PST) ROLL CALL Adam Tambone * Anders Ekholm, Ericsson Barry Katz, SiSoft Benny Lazer Benjamin P Silva Bob Cox, Micron * Bob Ross, Teraspeed Consulting Group Brian Arsenault * David Banas, Xilinx * Eckhard Lenski, Nokia Siemens Networks Eric Brock * Guan Tao, Huawei Technologies Gregory R Edlund Hazem Hegazy Huang Chunxing, Huawei Technologies John Figueroa John Angulo, Mentor Graphics Katja Koller, Nokia Siemens Networks Kevin Fisher Kim Helliwell, LSI Logic Lance Wang, IOMethodology Lynne Green * Mike LaBonte, Cisco Systems Mike Mayer, SiSoft * Moshiul Haque, Micron Technology * Pavani Jella, TI Peter LaFlamme Randy Wolff, Micron Technology Radovan Vuletic, Qimonda Robert Haller, Enterasys Roy Leventhal, Leventhal Design & Communications Sherif Hammad, Mentor Graphics Todd Westerhoff, SiSoft Tom Dagostino, Teraspeed Consulting Group Kazuyoshi Shoji, Hitachi Sadahiro Nonoyama Everyone in attendance marked by * NOTE: "AR" = Action Required. -----------------------MINUTES --------------------------- Mike LaBonte conducted the meeting. Call for patent disclosure: - No one declared a patent. AR Review: - None New items: - Anders: Why do we require [Voltage Range] for series models? - Bob: This was for consistency, to avoid rule branches - Adding special conditions makes a spider web - Simulators have no use for this - Bob: Some series devices were used to convert voltage levels - This is not important enough for a BIRD - Bob: The same applies to C_comp which is not always needed Continued review of the IBIS Quality Specification: 5.5.3. {LEVEL 2} [Ramp] test fixture has no reactives - We looked at the IBIS spec for [Ramp] - Anders: [Ramp] is not required for inputs, terminators, and series - Mike: [Ramp] disallows package effects, but waveforms allow it - Bob: This was added later, with IBIS 2.0 - Kumar had proposed adding more elements to the [Ramp] fixture - Reference voltage, for example - Mike: [Ramp] may have seemed less important at that time - Mike: Some model waveforms don't show the same dv/dt as [Ramp] - Anders: This mismatch can be a problem - Some simulators may use [Ramp] to decide timestep - Bob: This check should be deleted - Mike: Inclined to keep it - Eckhard: Keep it - Anders: Do we state that data for [Ramp] is linear? - Bob: It is just 2 points - Mike: Model makers either understand this or not - Bob: We should avoid having too many checks - Anders: Who uses this, model user or maker? - Mike: Model maker - Pavani: Keep it - Have never seen reactives used - Moshiul: Delete it - Have never seen reactives used - Model users have no way to know - Correlation with waveforms should do the trick - David: Delete it - Avoid checks that IBISCHK can't do - Company has to observe over 100 I/O standards - This is a burden for the vendor - Eckhard: But then users will have to do it - Mike: We could delete this and propose the IBISCHK enhancment - Pavani: A capacitive fixture could produce a sawtooth waveform - How would you separate rise and fall for a sawtooth? - Maybe we should disallow reactives for waveforms - Mike: This would be an extreme case - It would never settle to a static value - Bob: That just needs to be documented - For high speed simulation the edges are most important - Bob: We caution against reactives in the cookbook - If [Ramp] matches a waveform with reactives then Ramp may be wrong - Only the model generator knows - Mike is unable to meet next week Next meeting: 28 Oct 2008 11-12 AM EST (8-9 AM PST) Meeting ended at 12:05 PM Eastern Time.